Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-200.txt

Text File | 1994-12-08 | 45.9 KB | 1,352 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 01 Nov 92       Volume 1 : Issue 200

Today's Topics:

    fastQSort.p (Pascal port of  fastQsort.c)
    SUMMARY: How to <<Readln>> from a handle?
    bugs in Think C 5.0.3 floating point routines?
    Think C, Interrupts and restoring A5
    Patching GetResource
    How to detect movable modal WDEF?



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Matthew Xavier Mora)
Subject: fastQSort.p (Pascal port of  fastQsort.c)
Date: 28 Sep 92 22:58:59 GMT
Organization: SRI International

I don't remember seeing this get posted so I'll post another copy.
This is the Pascal version of Hadyn Huntley's fastQsort.c that was
posted here long ago. Since I posted a request for sorting code in pascal,
I thought I should post this for the net in case anyone else is
interested.

It could use a better memswap if someone has one.

Matt



{------------------------------------------------}
{ fastQsort port by Matthew Xavier Mora based on }
{ Hadyn Huntley fastqsort.c                      }
{ posted to C.S.M.P. on 09-28-92                 }
{                                                }
{Researched and written by:                      }
{                                                }
{        Haydn Huntley                                 }
{        Haydn's Consulting                            }
{        203 West Stone                                }
{        Fairfield, Iowa  52556                        }
{    [phone]                                 }
{                                                }
{    During the school year, I may be reached at the}
{ following address:                             }
{                                                }
{        Haydn Huntley                                 }
{        Eigenmann Hall #289                           }
{        Indiana University                            }
{        Bloomington, IN  47406                        }
{        [phone]                                }
{                                                }
{    E-mail:  [e-mail]        }
{------------------------------------------------}
unit fastqsort;

interface

    procedure FastQSort (base: Ptr; numberofRecords: longint; sizeofRecord:
longint);

implementation


    procedure FastQSort (base: Ptr; numberofRecords: longint; sizeofRecord:
longint);
        var
            gSize: longint;
            tmp, LowerLimit, UpperLimit: ptr;

        procedure memSwap (p, q: ptr; qSize: longint);

        begin
            BlockMove(p, tmp, qSize);
            BlockMove(q, p, qSize);
            BlockMove(tmp, q, qSize);
        end;

        function GetSize (var n: longint; last, first: ptr): integer;
        begin
            n := (ord(last) - Ord(first)) div gsize;
            GetSize := n;
        end;

        function cmpFn (aPtr, bPtr: ptr): integer;
        begin
            cmpFn := IUMagString(ptr(ord(aPtr) + 1), ptr(ord(bPtr) + 1), gsize,
gsize);
        end;

{ ------------- begin doFastQSort ------------------------ }
        procedure doFastQSort (first, last: ptr);
            var
                i, j: Ptr;
                n: longint;
        begin
    { first, last, i, and j are scaled by gSize in this function }

            while ((getsize(n, last, first)) > 1) do
                begin

            { use a random pivot }
                    memSwap(ptr(ord(first) + (abs(random) mod n) * gSize), first, gSize);

                    i := first;
                    j := last;

                    while (true) do
                        begin
                            i := Ptr(ord(i) + gSize);
                            while (ord(i) < ord(last)) and (CmpFn(i, first) < 0) do
                                i := Ptr(ord(i) + gSize);

                            j := Ptr(ord(j) - gSize);
                            while (ord(j) > ord(first)) and (CmpFn(j, first) > 0) do
                                j := Ptr(ord(j) - gSize);

                            if (ord(i) >= ord(j)) then
                                leave;

                            memSwap(i, j, gSize);
                        end;

                    if (j = first) then
                        begin
                            first := ptr(ord(first) + gSize);
                            cycle;
                        end;

                    memSwap(first, j, gSize);
                    if (ord(j) - ord(first)) < (ord(last) - (ord(j) + gSize)) then
                        begin
                            doFastQSort(first, j);
                            first := ptr(ord(j) + gSize);
            { equivalent to doFastQSort (j + gSize, last);        }
            { to save stack space                                }
                        end
                    else
                        begin
                            doFastQSort(ptr(ord(j) + gSize), last);
                            last := j;
            { equivalent to doFastQSort (first, j);            }
            { to save stack space                                }
                        end;
                end;
        end;
{ ------------- begin FastQsort ------------------------ }
    begin
    { setup the global variables used by fastQSort() }

        gSize := sizeofRecord;
        randseed := TickCount;
        tmp := NewPtr(gsize);                         {temp ptr for swapping}
  if tmp <> nil then
    begin
         { the args for fastQSort () must be scaled by gSize }
            doFastQSort(base, ptr(ord(base) + (numberofRecords) * gSize));
            DisposePtr(tmp);
   end;
    end;
end.

---------------------------

From: [e-mail] (Gary Czychi)
Subject: SUMMARY: How to <<Readln>> from a handle?
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Wed, 30 Sep 1992 20:09:39 GMT



Almost two weeks ago, I asked the net how this could be done:  Given a
normal handle to a chunk of data and read line for line (until the next CR)
from it.

So here it is. First, I've appended my posting, and then in alphabetical
order, the edited postings/mails from John B. Matthews
<[e-mail]>, Matthew Hall <[e-mail]>,
Peter N Lewis <[e-mail]> and Stepan Riha
<[e-mail]> (in alphabetical order).

I use the solution in my extended class library for the THINK Pascal class
library in a class called "CPrepareText".  It's for all kind of text
preparations, conversions and validations.  If you want it, just drop me a
mail.  I will also post it to the TCL-Talk archive at
ftp.brown.edu:/pub/tcl.

- ----------------------   Summary   ---------------------------------------

I have been told that the Mac (in fact any computer) is very slow reading
textual input from a file line by line.

And in my application, I have already read in the text of a file in one big
chunk and pass the handle to the place where I process the data.

Now, is there any way for me, to read some of the lines in this handle? I
only need about 10 lines from the top and separate it from the rest, which
is being diplayed in a window as one big part.

I've tried to type coerce the handle to a str255 handle, but then I get a
range error (of course).

If there is no obvious or easy solution, how could I access the data in my
handle byte for byte and then put everything into a Str255 until the next
CR is detected?

- --------------------

Date:  Wed, 16 Sep 1992
From:  "John B. Matthews" <[e-mail]>
Message-ID:  <[e-mail]>
To:  [e-mail]
Subject:  How to <<Readln>> from a text referenced by a handle??


function ReadString(h: CharsHandle; var index: Integer): Str255;
{Get characters from index to CR (or 255 characters) and
 update index to point to start of next string}

var i, limit: Integer; s: Str255;

begin
  limit:= min(GetHandleSize(Handle(h)), SizeOf(Chars));
  i:= index;
  while (h^^[i]<>chr(13)) and (i<limit) and ((i-index)<255) do
    i:= i+1;
  BlockMove(pointer(ord(h^)+index), pointer(ord(@s)+1), i-index);
  s[0]:= chr(i-index);
  index:= i+1;
  ReadString:= s;
end;

The types Chars and CharsHandle are defined in TextEdit. The function
min should be easy although you may want to make limit a LongInt to avoid
type casts. I haven't tested this; it may be fragile for extreme data
(eg. empty handle or all empty lines)

John B. Matthews, [e-mail], disclaimer:= myViews <> WSU
"Whom the gods would destroy, they first invite to program in C"

- --------------------

 to:
 IN%"[e-mail]"
 Reply: How to <<Readln>> from a  handle?


Thanks a lot for your reply. In your code you use the BlockMove function
which I've already seen (in IM) but never used before.  What exactly does
it do?  Does it really move the data or does it copy of the data?

If it moves the data, what happens to the original data?  Will it be reduced by
the amount of data which was moved and the size of it adjusted afterwards? That
would be cute.

- --------------------

    17-SEP-1992
From:   IN%"[e-mail]"  "John B. Matthews"
Subj:   RE: How to <<Readln>> from a  handle?

BlockMove (srcPtr, destPtr: Ptr; byteCount: LongInt); copies byteCount
bytes from srcPtr to dstPtr. It works even if the source and destination
overlap, although they don't in my example.

The original data is undisturbed, unless the source and destination
overlap. There is no adjustment of size: the pointers are just addresses in
memory. In my example, srcPtr is index bytes into a relocatable block while
dstPtr is the second byte of a string on the stack.

It would have been nice to just write @h^^[index] and @s[1], but the @
operator won't work on elements of a packed array. It's OK to dereference
h the way I did (without locking it) since BlockMove won't move memory.

- --------------------

From:  "John B. Matthews" <[e-mail]>
To:  [e-mail]
Subject:  How to <<Readln>> from a text referenced by a handle??

This works much better:-)

program ReadStr;
  var
    wRect: Rect;
    err: OSErr;
    fRefNum: Integer;
    i, count: LongInt;
    h: Handle;
    s: Str255;

  procedure ReadString (h: Handle; var index: LongInt; var s: Str255);
  {Copy characters from index to CR (up to 255) into s}
  {and update index to point to start of next string}
    var
      i, limit: LongInt;
  begin
    limit := GetHandleSize(h);
    i := index;
    while (CharsHandle(h)^^[i] <> chr(13)) and
          (i < limit) and ((i - index) < 255) do
      i := i + 1;
    BlockMove(pointer(ord(h^) + index), pointer(ord(@s) + 1), i - index);
    s[0] := chr(i - index);
    index := i + 1;
  end;

begin
  InitCursor;
  wRect := ScreenBits.bounds;
  InsetRect(wRect, 50, 50);
  SetTextRect(wRect);
  ShowText;
  err := FSOpen('ReadStr.p', 0, fRefNum);
  err := GetEOF(fRefNum, count);
  h := NewHandleClear(count);
  if h <> nil then
    err := FSRead(fRefNum, count, h^);
  err := FSCLose(fRefNum);
  i := 0;
  while i < count do
    begin
      ReadString(h, i, s);
      WriteLn(s)
    end
end.

- --------------------

    21-SEP-1992
From:   IN%"[e-mail]"  "John B. Matthews"
Subj:   RE: How to <<Readln>> from a  handle?


I was examining the generated code from the HReadLn method and noticed
a potential problem: I examine each byte of the source text with the
expression CharsHandle(h)^^[i] <> chr(13).

The relevant instruction is MOVE.B $00(A0,D7.W),D0 (address register
indirect with index and displacement). The index register is treated
as a sign extended word by default. This has the advantage of
working correctly on 68000 machines (no odd address generation), but
I think it breaks if i exceeds 32767.

The alternative, pointer(ord(h^) + i)^ <> 13, would break with an odd
address error on 68000 machines. (A similar expression in the first
argument to BlockMove is safe since BlockMove does the right thing.)

Is text > 32767 important? I guess I'd at least note the limitation
in the comments.

John

- --------------------

    15 Sep 92
From: [e-mail] (Matthew Hall)
Subject: How to <<Readln>> from a text referenced by a handle??


Hello -

There are a number of ways to do this - To start off, first lock your
handle.
Now, you can just scan.  How you would do this is to declare

Type CharList = ^CharArray;
     CharArray = array[0..0] of char;

var TheCharList :  CharList;
    FileData :   Handle;
    FilePos  : LONGINT;
    CharPos,NumLine  : integer;
    TheStrs : array[1..MAXLINES] of Str255;
    TempStr :  Str255;

{FilePos records how far you are into the data, NumLine records which
line you are currently on, CharPos is how many characters you are into
the current line, and TheStrs are the strings you are placing the
lines into.  A charlist is for typecasting, to fool THINK into
thinking you are dealing with a stream of characters rather than just
a huge block of bytes(same thing really.  That's why some people like
C, you don't have to fool the compiler).  You set the address of
TheCharList to the Master Pointer for TheFileData, and you can read of
the characters just like an array.  WARNING: This method wont work if
you try to access characters further than 32767 into the file.  That's
a little more complicated and THINK has some silly quirks}

begin
HLock(FileData);
TheCharList:=CharListPtr(FileData^);
FilePos:=0
NumLines:=0;
repeat
  NumLine:=NumLine+1;
  Charpos:=1
  While TheCharList[CharPos]<><cr> do
    begin
      TempStr[CharPos]:=TheCharList[CharPos];
{Remember, Type Str255 = array[0..255] of char, where Str[0] is the
length of the string}
      CharPos:=CharPos+1;
    end
  TempStr[0]:=chr(charpos-1); {Set the length byte of the string}
  TheStrs[NumLine]:=TempStr;
until NumLine=MAXLINES;

This should work - I forgot how to check if a character is a <cr> tho' Of
course this could be made faster - A First step would be to remove the
TempStr and replace it with TheStrs[numline][charpos]. There are other
methods, you could use BlockMove.  Find the locations of the <cr>'s and
just blockmove chunks into your strings.  However you still have to scan
for the <cr>'s, and that's the slowest part.  I don't think, though, that
this method will be noticible even.  Unless you are reading many lines, or
from many, many files. If you are saving the files yourself, you could save
them in string format,and it would be much quicker to retrieve them, but no
other application would make sense of them.

Like I say, this method should be quick enough unless your needs are
extreme. at 10 Mhz, if this compiles to 100 instructions at 100 cycles per
intruction ( a bad case) you still get 1000 characters per second. (If your
using TP's debug option, it may be 1/20'th of that)  Which should be more
than 10 lines/second.

- -hope this helps
- -matt hall

- --------------------

    16 Sep 92
From: [e-mail] (Peter N Lewis)
Subject: Re: How to <<Readln>> from a text referenced by a handle??


{$R-}
procedure ReadALine(h:handle; var s:str255);
var
  p:ptr;
  size,len:longInt;
begin
  p:=h^;
  size:=GetHandleSize(h);
  len:=0;
  while (size>0) & (p^ <> 13) do begin
    p:=ptr(ord(p)+1);
    size:=size-1;
    len:=len+1;
  end;
  if len>255 then len:=255;
  s[0]:=chr(len);
  BlockMove(h^,@s[1],len);
  if size>0 then begin
    p:=ptr(ord(p)+1); { Skip over the <cr> }
    size:=size-1;
    BlockMove(p,h^,size);
  end;
  SetHandleSize(h,size);
end;

I tested this code, it seems to work ok.  Note, if you were going to read
lots of lines, you'd be better keeping an offset, and avoiding the block
move all the time, but the above will work ok, and isn't *that* inefficent,
it depends how many times you want to call ReadALine, if its 10 or 20, no
problem, if its 10 or 20 thousand, then some rethinking would be
necessary...
   Peter.

Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

- --------------------

    16 Sep 92
From: [e-mail] (Rhys Hollow)
Subject: Re: How to <<Readln>> from a text referenced by a handle??


[e-mail] (Peter N Lewis) gives a useful example of
implementing a Readln with a handle-referenced block of text :

>{$R-}

...

Hmm, don't forget to turn Range Checking back on Pete!

Rhys.

Rhys Hollow ([e-mail]) "ee'er by gum he's a bad'un!" -DangerMouse.

- --------------------

    17-SEP-1992
From:   IN%"[e-mail]"  "Peter N Lewis"
Subj:   RE: How to <<Readln>> from a  handle?


> Does it really move the data or does it copy of the data?

No, it copies the data.  It will work correctly even if the source range
and destination range overlap.

>If it moves the data, what happens to the original data?  Will it be reduced by
>the amount of data which was moved and the size of it adjusted afterwards? That
>would be cute.

No, but there is a procedure callen Munger, documented in IM1, which is
totally cryptic, and which could have been used to do a bit of it, but
figuring out munger is a pain.

BlockMove simply copies the block of memory, the original area is untouched
(unless the destination and source areas overlap).

- --------------------

    Tue, Sep 15, 1992
From: [e-mail] (Stepan Riha)
Subject:  How to <<Readln>> from a text referenced by a handle??


Gary, I haven't worked with Pascal in a while but you should be able to
dereference the handle and assign the value to a Pointer to a Character.
Then you could dereference the pointer and call the successor function on
it.

Procedure Foo(Handle h, integer len, var Str255 str);
Const
        CR = #13;       (* or however you declare a NewLine in Pascal *)
Var
        cPtr : Pointer TO Char;
        i : Integer;
        str : Str255;
Begin
        cPtr := h^;
        i := 1;
        while i<=len AND i<=255 AND cPtr^ <> CR do
                begin
                        str[i] = cPtr^;
                        cPtr := Succ(cPtr);
                        i := Succ(i);
                end;
        str[0] := i-1;
end;

I'm not too sure about my syntax but this should do it.

        - Stepan

Stepan Riha -- [e-mail]

- --------------------
- --------------------

Thanks a lot to all who responded!


  Gary

    Gary T. Czychi          University of St.Gallen

       [e-mail] (preferred host)
         czychi at csghsg52   (=bitnet)
           [e-mail]
             Switzerland
              -




---------------------------

From: [e-mail] (Simon Gray)
Subject: bugs in Think C 5.0.3 floating point routines?
Date: 23 Sep 92 11:18:54 GMT
Organization: Bath University Computing Services, UK

Dear Netters

I have come across a  not so amusing problem with Think C 5.0.3
running on a mac IIci with 8Mb RAM, system 7.0.1 and tuneup 1.1.1.

If I recompile the ANSI library with 4-byte ints turned on, the following
code fails with a bomb:

#include<stdio.h>
#include<stdlib.h>

main()
{
char a[20];
scanf("%s", a);
printf("%lf\n", atof(a));
}

  :and by debugging the ANSI library source files, it crash appears to occur
on calls to the function fp68k(). By adding short casts, indicated by
my comments in the code below, the  above code will run successfully.

- ---- code segment extracted from scanf.c ANSI library sources folder ---

fp68k(&excp, (short)FPROCENTRY); /* ccssrg - added short cast */
    if (d->sig[0]) {
        fp68k(d, p, (short) (FOD2B + code));
        fp68k(&excp, (short)FGETENV); /* ccssrg - added short cast */
        fp68k(p, &kind, (short) (FOCLASS + code));
        if (kind < 0)
            kind = -kind;
        if (kind == FCINF || (excp & (OVERFLOW<<8)))
            c = 'I';
        else if (kind == FCNORM && !(excp & (UNDERFLOW<<8)))
            goto done;
        errno = ERANGE;
    }
- ------------------ end segment ----------------

Unfortunately, it has become obvious that this is not the complete answer
because a larger project that some colleagues are working on does not
run successfully, using calls to fp68k(), even with the short casts added.

I have spoken to U.K. Symantec Tech Support (based in Holland!) and they
have been 1) somewhat unhelpful
          2) surprised at the bug
          3) unable to suggest any solutions

Has any one out in netland had any similar experiences with these floating
point functions and have you found any other or better solutions?

If people would like to email their comments or thoughts to me, I will
summarise to the net.


Simon Gray
Small Systems Team
Bath University Computing Services
- ------------------------
email: [e-mail]
- ------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Tony Gedge)
Date: 23 Sep 92 13:55:07 GMT

In <[e-mail]> [e-mail] (Simon Gray) writes:
>I have come across a  not so amusing problem with Think C 5.0.3
>running on a mac IIci with 8Mb RAM, system 7.0.1 and tuneup 1.1.1.

The problem you mention has been in THINK C 5.0, 5.0.1 and 5.0.2.  I ran into
it trying to port GhostScript to the mac.  In my case, the program *ran* more
or less OK, however when you exited the compiler, the machine would shut down :(

>If I recompile the ANSI library with 4-byte ints turned on, the following
>code fails with a bomb:

[source code deleted]

>  :and by debugging the ANSI library source files, it crash appears to occur
>on calls to the function fp68k(). By adding short casts, indicated by
>my comments in the code below, the  above code will run successfully.

[code segment deleted]

>Unfortunately, it has become obvious that this is not the complete answer
>because a larger project that some colleagues are working on does not
>run successfully, using calls to fp68k(), even with the short casts added.

This problem occurs in math.c printf.c and scanf.c (as I'm sure you
are now aware! :-)  Did you get the two other related calls which have the
same problem? [elems68k() and decstr68k()].

I think it occurrs because of the way in which the functions fp68k(),
decstr() and elems68k() are declared.  If I remember correctly, the compiler
``promotes'' constants to a ``int'' if it doesn't have any prototype or cast
to tell it otherwise.

>I have spoken to U.K. Symantec Tech Support (based in Holland!) and they
>have been 1) somewhat unhelpful
>          2) surprised at the bug
>          3) unable to suggest any solutions

Doesn't surprise me if this bug has got through 3 patch levels so far :)
Mind you, if everyone was like me and never bothered to tell them then maybe
its a little understandable :) -- although it would appear that nobody
properly tested the stdio library under 4-bit int mode..

>Has any one out in netland had any similar experiences with these floating
>point functions and have you found any other or better solutions?

The only thing I can suggest is to make sure you get all fp68k calls *and*
elems68k() calls (I think there is one of those somewhere embedded in a macro)
Since I ``fixed'' this a year or so back I can't remember exactly what changes
I made, and you might have hit some other problem with the stdio library.

>If people would like to email their comments or thoughts to me, I will
>summarise to the net.

Have you been burnt by this one in console.c?
    InitGraf(NewPtr(206) + 202);
This line means (amoungst other things) that you can't use offscreen bitmaps
and the console at the same time, because the Quickdraw globals won't be set
up in the correct spot.  Took me ages to work out why the Quickdraw globals
were all stupid in my software!

Good luck with your product,

Tony Gedge.

- --
| Computer Science Department,       |  [e-mail]   (Tony Gedge)  |
| University of Queensland,          |  --------------------------------  |
| Australia.                         |  "cc stands for Cryptic Crossword" |
| FAX: [phone].               |  PH : [phone]               |

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 24 Sep 92 14:34:05 GMT
Organization: Symantec Corp.

OK, I guess it's time to run to THINK C's rescue.. :)

>>>>> On 23 Sep 92 13:55:07 GMT, [e-mail] (Tony Gedge) said:

 > In <[e-mail]> [e-mail] (Simon Gray) writes:

>>If I recompile the ANSI library with 4-byte ints turned on, the
>>following code fails with a bomb:

 > [source code deleted]

>>  :and by debugging the ANSI library source files, it crash appears
>>to occur on calls to the function fp68k(). By adding short casts,
>>indicated by my comments in the code below, the above code will run
>>successfully.

 > [code segment deleted]

>>Unfortunately, it has become obvious that this is not the complete
>>answer because a larger project that some colleagues are working on
>>does not run successfully, using calls to fp68k(), even with the
>>short casts added.

 > This problem occurs in math.c printf.c and scanf.c (as I'm sure you
 > are now aware! :-) Did you get the two other related calls which
 > have the same problem? [elems68k() and decstr68k()].

 > I think it occurrs because of the way in which the functions
 > fp68k(), decstr() and elems68k() are declared.  If I remember
 > correctly, the compiler ``promotes'' constants to a ``int'' if it
 > doesn't have any prototype or cast to tell it otherwise.

I'll bet money that you didn't just turn on the "4 byte ints" option,
you also turned on the "enums are always ints" option as well. If
that's the case, then the "enums are always ints" option is the source
of your problems. The SANE header file (and possibly other toolbox
headers as well) will not compile correctly with that option on, as
you've seen. Since you're just recompiling ANSI, you can get by with
just using "4 byte ints" only.

There are a couple reason why SANE.h is "broken" in this way, a
summary is: (1) we wanted to use the MPW C headers with the mininum of
change, (2) we wanted to support full ANSI C, including int sized
enums, and (3) MPW C has no "enums are always ints" option, so it
isn't an issue for MPW C users. I would agree that this should be
covered in the User Manual or in the ReadMe file.

 > Have you been burnt by this one in console.c?

 >     InitGraf(NewPtr(206) + 202);

 > This line means (amoungst other things) that you can't use
 > offscreen bitmaps and the console at the same time, because the
 > Quickdraw globals won't be set up in the correct spot.  Took me
 > ages to work out why the Quickdraw globals were all stupid in my
 > software!

Well, there was a warning about exactly that in the C 4.0 Standard Lib
Ref, I have no idea why it was removed from the 5.0 doc :-(. I'll make
sure it gets added back in the next release.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

From: [e-mail] (Tom Emerson)
Subject: Think C, Interrupts and restoring A5
Date: 23 Sep 92 13:04:32 GMT
Organization: University of Vermont, EMBA Computer Facility

In article <ejohnson.717224121@void> [e-mail] (Eric E. Johnson) writes:

   I suspect that my a5 is incorrect, and that this is the source of the
   problem.  So, I pulled out Inside Macintosh, and checked to see how to
   set and restore A5 for my application.  IM says they are SetUpA5 and
   RestoreA5, however, Think C only had one that corresponded to SetUpA5.

According to IM-VI, p. 28-13, SetupA5/RestoreA5 cause problems with some
optimizing compilers, and as such Apple has defined two new procedures,
SetCurrentA5 and SetA5. These are defined in IM-VI pp.28-13--16 and M.ME.4-25.

   What did Think C rename RestoreA5 to?  I checked the Apple includes
   that came with Think C, but no luck.  I checked the manual, but there
   was only a discussion of setting and restoring A4.  Does Think C use
   A4 instead of A5?

SetCurrentA5 and SetA5 are defined in OSUtils.h. THC provides a mechanism to
address your global data off A4 rather than A5. We recommend this method over
playing games with A5, though that is totally up to you.

Tom
- --
   Tom Emerson                                    Technical Support
   Language Products Group                     Symantec Corporation
            Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Eric E. Johnson)
Date: 24 Sep 92 17:50:10 GMT
Organization: University of Illinois at Urbana

>   I suspect that my a5 is incorrect, and that this is the source of the
>   problem.  So, I pulled out Inside Macintosh, and checked to see how to
>   set and restore A5 for my application.  IM says they are SetUpA5 and
>   RestoreA5, however, Think C only had one that corresponded to SetUpA5.

>According to IM-VI, p. 28-13, SetupA5/RestoreA5 cause problems with some
>optimizing compilers, and as such Apple has defined two new procedures,
>SetCurrentA5 and SetA5. These are defined in IM-VI pp.28-13--16 and M.ME.4-25.

Here's the next question.  The code in IM-VI, on page 28-15,
demonstrates how to get the application's A5 global variable by
copying it out of the notification manager's field nmRefCon.  Fine, I
understand how to set that up, but what if I'm using something like
MacTCP's call back routine where the TCPNotify routine, which runs at
interrupt time, has no way of knowing what the application's A5 global
was to begin with.

>SetCurrentA5 and SetA5 are defined in OSUtils.h. THC provides a mechanism to
>address your global data off A4 rather than A5. We recommend this method over
>playing games with A5, though that is totally up to you.

What's the advatange of using A4 over A5?

Eric

+++++++++++++++++++++++++++

From: [e-mail] (Tom Emerson)
Date: 24 Sep 92 21:55:50 GMT
Organization: University of Vermont, EMBA Computer Facility

Eric Johnson writes:

[previous message excerpts deleted]

> Here's the next question.  The code in IM-VI, on page 28-15,
> demonstrates how to get the application's A5 global variable by
> copying it out of the notification manager's field nmRefCon.  Fine, I
> understand how to set that up, but what if I'm using something like
> MacTCP's call back routine where the TCPNotify routine, which runs at
> interrupt time, has no way of knowing what the application's A5 global
> was to begin with.

This type of situation is also discussed in IM-VI, p. 23-18. I'm not
familiar with the call back routines in MacTCP, but in effect you create
a new data structure that contains as its first element the information
the call back routine expects, and add to this a long to hold the value
of A5. Then you just put some assembly glue in your function to grab the
stored value of A5.

> What's the advatange of using A4 over A5?

By using the THINK A4 routines to handle globals in interrupts and such
things you completely avoid the need to store off A5 someplace where your
routine can find it. The dirty work is done for you.

Tom
- --
   Tom Emerson                                    Technical Support
   Language Products Group                     Symantec Corporation
            Internet: [e-mail]

---------------------------

From: [e-mail] (Dave Polaschek)
Subject: Patching GetResource
Date: 22 Sep 92 15:01:34 GMT
Organization: LaserMaster Corp

In article <[e-mail]> [e-mail] (Keith
Rollin) writes:
> I patch GetResource for globally replacing system resources. Once the
> system has a handle to your resource, LoadResource will continue to get
> your resource.
>

Keith (and any other wizards who might care to comment),

Doesn't this put quite a bit of extra overhead into every GetResource call?
I've considered using this type of patch to detect other applications loading
resources, and decided against doing so because of the added overhead (and I
only wanted to make the patch while my application was running).  It would
seem to me that this could have a pretty big impact on system performance in
general.

If the performance hit of this is going to be fairly minimal, I might
consider using it, but it still seems to me that this is going to slow down
an just about everything a user is going to do on a mac.  To be honest, I'm
not sure if there is another way to detect something like changing the MBDF
(or in my case noticing when the PAPA resource in the LaserWriter driver is
touched, so I can detect QuicKeys' Choosy extension), but I continue to
search for a better solution.

Just my two cents worth.

- -Dave

> In the following snippet:
>
> o "gMyRefNum" is the resource refNum for my INIT, which holds my MBDF
> o My INIT opens itself on the first call to InitAllPacks, and reshuffles
> the
>   resource chain so that it appears behind the System File.
> o MyGetResource saves extra registers because of the comment on page I-113
>   of IM.
> o "oldGetResource" is a global variable holding the address returned by
>   GetToolTrapAddress when I patched GetResource.
> o I used THINK C, allowing me the use of A4 globals and inline assembly.
> static pascal Handle    MyGetResource(ResType resType, short resID)
> {
>     short    oldResFile, newResFile;
>     Handle    result;
>
>     asm {
>         movem.l    a1-a3/d1-d7,-(sp)
>     }
>
>     SetUpA4();
>
>     newResFile = oldResFile = -1;
>
>     if (gMyRefNum != 0) {
>         //
>         // If anyone ever asks for the standard MBDF, give them ours.
>         //
>         if (resType == 'MBDF' && resID == 0) {
>             newResFile = gMyRefNum;
>             resID = 1000;
>         }
>     }
>
>     if (newResFile != -1) {
>         oldResFile = CurResFile();
>         UseResFile(newResFile);
>     }
>
>     result = oldGetResource(resType, resID);
>
>     if (oldResFile != -1)
>         UseResFile(oldResFile);
>
>     RestoreA4();
>
>     asm {
>         movem.l (sp)+,a1-a3/d1-d7
>     }
>
>     return result;
> }
>
> -----
> Keith Rollin
> Phantom Programmer
> Taligent, Inc.

Dave Polaschek            Internet:[e-mail]
LaserMaster Corp. R&D              ICBMNet:44^59'N 93^13'W
7156 Shady Oak Road                     AppleLink:LASERMAX
Eden Prairie, MN 55344                   ATTNet:6129439204

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 23 Sep 92 20:14:02 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Dave Polaschek) wrote:
>
> In article <[e-mail]> [e-mail] (Keith
> Rollin) writes:
> > I patch GetResource for globally replacing system resources. Once the
> > system has a handle to your resource, LoadResource will continue to get
> > your resource.
> >
>
> Keith (and any other wizards who might care to comment),
>
> Doesn't this put quite a bit of extra overhead into every GetResource call?
> I've considered using this type of patch to detect other applications loading
> resources, and decided against doing so because of the added overhead (and I
> only wanted to make the patch while my application was running).  It would
> seem to me that this could have a pretty big impact on system performance in
> general.
>
> If the performance hit of this is going to be fairly minimal, I might
> consider using it, but it still seems to me that this is going to slow down
> an just about everything a user is going to do on a mac.  To be honest, I'm
> not sure if there is another way to detect something like changing the MBDF
> (or in my case noticing when the PAPA resource in the LaserWriter driver is
> touched, so I can detect QuicKeys' Choosy extension), but I continue to
> search for a better solution.
>

Well, take a look at what's going on in the patch, compared to what
GetResource does. Before the chained call to GetResource:

    asm {movem.l    a1-a3/d1-d7,-(sp)}
    SetUpA4();
    newResFile = oldResFile = -1;

    if (gMyRefNum != 0) {
        if (resType == 'MBDF' && resID == 0) {
            newResFile = gMyRefNum;
            resID = 1000;
        }
    }
    if (newResFile != -1) {
        oldResFile = CurResFile();
        UseResFile(newResFile);
    }

This stuff will execute in just about nothing flat. The only thing you
could point to are the calls to CurResFile() and UseResFile(). Neither of
these is a heavy-weight routine, and so shouldn't add much overhead.
Besides, they only get executed IF the system is asking for MBDF(0).

Following the chained call to GetResource:

    if (oldResFile != -1)
        UseResFile(oldResFile);
    RestoreA4();
    asm { movem.l (sp)+,a1-a3/d1-d7 }
    return result;

Again, none of this will take much time. The call to UseResFile will only
get called if we changed the current resfile above, which only happens if
the system is asking for MBDF(0). On a normal GetResource call, the
following happens:

- - Save registers
- - Setup A4
- - Set two locals to -1
- - Check gMyRefNum
- - Check resType (will almost always return FALSE)
- - Check newResFile (will almost always return FALSE)
* Call the original GetResource (chug, chug, chug)
- - Check OldResFile (will alsmost always return FALSE)
- - Restore A4
- - Restore registers
- - return result

None of the items marked with "-" will add appreciable overhead to the
actual heart of the GetResource call.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Sak Wathanasin)
Subject: How to detect movable modal WDEF?
Date: 23 Sep 92 14:19:21 GMT
Organization: Network Analysis Ltd

I'm working on an appl that needs to run in both sys 6 & 7. I would like to
use the movable modal for my dialogues, but fall back to plain old modal in
sys 6. How can I tell if the movable modal WDEF is available? I can't see
any Gestalt calls that will help... Thanks in advance for any ideas.


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: [phone]
AppleLink: NAN.LTD           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Nicholas Jackiw)
Date: 23 Sep 92 16:59:16 GMT
Organization: Whole Earth 'Lectronic Link

In article <[e-mail]> [e-mail] writes:
>I'm working on an appl that needs to run in both sys 6 & 7. I would like to
>use the movable modal for my dialogues, but fall back to plain old modal in
>sys 6. How can I tell if the movable modal WDEF is available? I can't see
>any Gestalt calls that will help... Thanks in advance for any ideas.
>
>Sak Wathanasin

At the time Movable-Modal was released, one was encouraged to grab a
copy of it with ResEdit and stick it into your application's resource
fork.  Of course, this limits you to the functionality and bug-proofery
of a specific copy, but you can be fairly sure Apple won't be releasing
further upgrades of a 6.0 WDEF. (I haven't tried running the 7.0 WDEF
under 6.0.)

Maybe Jim Reekes, who's on the net, could comment.  He wrote it, I believe.




- --
                              --- * ---
Nick Jackiw                  [e-mail]   | [e-mail]
Key Curriculum Press, Inc.   Applelink:KEY.EDUSOFT | [phone]
                              --- * ---

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 23 Sep 92 18:26:34 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] writes:
>I'm working on an appl that needs to run in both sys 6 & 7. I would like to
>use the movable modal for my dialogues, but fall back to plain old modal in
>sys 6. How can I tell if the movable modal WDEF is available? I can't see
>any Gestalt calls that will help... Thanks in advance for any ideas.

I don't know of any way to check for the moveable-modal capability other
than checking for System version >= 7.0.  I know that Apple says that this is
a Bad Thing to do, but I think here it's probably pretty safe.  I mean, how
likely is it that a future version will _omit_ the moveable-modal window
variation??

One more suggestion: if the moveable-modal is unavailable, fall back to
noGrowDocProc, not dboxProc -- it looks much more like the moveable-modal.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Carl W. Haynes III)
Date: 23 Sep 92 22:09:30 GMT
Organization: Purdue University

In article <[e-mail]> [e-mail] writes:
>
>One more suggestion: if the moveable-modal is unavailable, fall back to
>noGrowDocProc, not dboxProc -- it looks much more like the moveable-modal.

I also go ahead and draw a black rectangle a couple pixels in
to make it look even more like the movable modal. Only the experts
can tell the difference :=>

There aughta be a gestalt selector for this, dontcha think.

- --
Carl W. Haynes III
Haynes Consulting Services        ||  [e-mail] <-- temp. out of order
PO Box 2715                       ||  [e-mail]
W. Lafayette, IN 47906            ||  [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 24 Sep 92 04:01:49 GMT
Organization: cellular

[e-mail] (Carl W. Haynes III) writes:

>In article <[e-mail]> [e-mail] writes:
>>
>>One more suggestion: if the moveable-modal is unavailable, fall back to
>>noGrowDocProc, not dboxProc -- it looks much more like the moveable-modal.

>I also go ahead and draw a black rectangle a couple pixels in
>to make it look even more like the movable modal. Only the experts
>can tell the difference :=>

Overkill. Just go ahead and use 5 for the variation code, under both
System 6 and System 7. The system will substitute a normal modal under
6. I gone and done it. I don't think it as any accident on Apple's part.

>There aughta be a gestalt selector for this, dontcha think.

Yup.
- --
 Pete Gontier // EC Technology // [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mimir Reynisson)
Date: 24 Sep 92 08:53:46 GMT

What about using GetResource? WDEF's are resources after all.
Just keep your Sys 6 WDEF ID different from that of Sys 7, and
if you cant load the Sys 7 WDEF with GetResource then open your
windows using the Sys 6 WDEF ID.

This should be a lot better method than checking if you have system 7,
for after all some people have ResEdit.

+++++++++++++++++++++++++++

From: [e-mail] (Sak Wathanasin)
Date: 24 Sep 92 12:22:06 GMT
Organization: Network Analysis Ltd


In article <6![e-mail]> (comp.sys.mac.programmer), [e-mail] (Pete Gontier) writes:

> Overkill. Just go ahead and use 5 for the variation code, under both
> System 6 and System 7. The system will substitute a normal modal under
> 6. I gone and done it. I don't think it as any accident on Apple's part.

I've just tried this, and it works fine. Many thanks to everyone who responded.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

uucp:      ...!uknet!nan!sw  Phone: [phone]
AppleLink: NAN.LTD           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 27 Sep 92 12:40:44 GMT
Organization: Personal

In article <6![e-mail]>, [e-mail] (Pete Gontier)
wrote:
>
> [e-mail] (Carl W. Haynes III) writes:
>
> >In article <[e-mail]> [e-mail] writes:
> >>
> >>One more suggestion: if the moveable-modal is unavailable, fall back to
> >>noGrowDocProc, not dboxProc -- it looks much more like the moveable-modal.
>
> >I also go ahead and draw a black rectangle a couple pixels in
> >to make it look even more like the movable modal. Only the experts
> >can tell the difference :=>
>
> Overkill. Just go ahead and use 5 for the variation code, under both
> System 6 and System 7. The system will substitute a normal modal under
> 6. I gone and done it. I don't think it as any accident on Apple's part.


Overkill???  users want to be able to move the damn thing out of the way so
that they can see what is going on behind it, and this is so cheap to do as
pales beside the alternative of getting a bad review or even answering the
odd letter/phone complaint.

Provide your own as a fallback to the officious version, and tell any user
who ResEdit's your fallback out from under you to put it back by golly.


> >There aughta be a gestalt selector for this, dontcha think.
>
> Yup.
> --
>  Pete Gontier // EC Technology // [e-mail]

Ayup

- --

Dana S Emery <[e-mail]> | "Novo, de Novo,
                                  |     de novo, de no-o-o-o-o---,
                                  | Novemba come an' dey gonna go home."

+++++++++++++++++++++++++++

From: [e-mail] (Humayun Lari)
Date: 29 Sep 92 00:25:58 GMT
Organization: The University of North Carolina at Chapel Hill

> [e-mail] (Carl W. Haynes III) writes:
[regarding using a regular noGrowDocProc if the movable-modal dialog isn't
around]
>I also go ahead and draw a black rectangle a couple pixels in
>to make it look even more like the movable modal. Only the experts
>can tell the difference :=>

Uh-oh. As all of the "eleven developers" (to quote Tog) who've read the human
interface note on movable-modal dialogs will attest, trying to make a regular
window look like a movable modal is a Bad Thing (tm). People are already
confused enough. :-)

'Course, we also have those wonderful DOS-escapees who implement movable-modal
dialogs that can't be moved... <sigh>

Humayun Lari
([e-mail])

---------------------------

End of C.S.M.P. Digest
**********************